量化交易系统

0. 系统概览

什么是量化交易系统

量化交易（Quantitative Trading）是用数学模型取代主观判断进行交易决策的交易方式。一个"系统"则是指把这一过程工程化——把数据、特征、策略、回测、风控、执行、对账、复盘八段链路连成一条"不漏数据、不串时间、不丢订单"的流水线。量化交易系统 = 执行 + 验证 + 风控 + 执行质量，缺了后三样，只是自动化的壳。

组件图（结构图 · 宏观总览）：八段链路——数据接入→特征工程→信号生成→组合构建→风险控制→订单执行→成交对账→监控复盘，含两条反馈闭环

核心认知：回测 ≠ 实盘

一个量化策略从"在 notebook 里看到一条漂亮的累计收益曲线"走到"在真实账户里持续产生 PnL"，至少要穿过四套环境：研究（Research）→ 回测（Backtest）→ 模拟交易（Paper Trading）→ 实盘（Live）。每一步都过滤掉一批"原本以为成立"的假设。

1. 行为视图（系统做什么）

1.1 用例图：整体行为

先从最宏观的视角看系统对外提供的全部能力，以及谁在使用它们。

用例图（行为图）：系统整体行为——四类参与者 × 九类核心用例

1.2 活动图：从想法到实盘订单

围绕最核心的主流程逐步细化：一个策略想法如何穿过四套环境，最终变成一笔实盘订单，并形成闭环反馈。

活动图（行为图 · 主流程）：四套环境递进——每跨一道环境，就过滤掉一批不成立的假设

把这段流程落到工程上，关键是"环境差异收敛到适配器"。下面是最小可运行的跨环境数据接口演示：

# 环境适配器：同一接口，不同实现
class DataSource(ABC):
    @abstractmethod
    def get_history(self, symbol, start, end): ...

class BacktestSource(DataSource):   # 读历史仓库，禁未来数据
    def get_history(self, symbol, start, end):
        df = hist_store.query(symbol, start, end)
        return df.shift(1)          # 信号只用 T-1 及以前信息（防前视）

class LiveSource(DataSource):       # 接实时行情
    def get_history(self, symbol, start, end):
        return live_feed.bars(symbol, start, end)

1.3 时序图：一次实盘下单的完整交互

主流程里"订单执行"这一段，涉及策略、风控、OMS、EMS、券商、交易所多个组件。时序图把它们之间的消息往来按时间展开。

时序图（行为图 · 细化）：一次实盘下单——策略→事前风控→OMS→EMS→券商→交易所→回报→对账

对应到代码，就是 Broker 抽象接口 + OMS 状态更新：

# 执行层：统一 Broker 接口
class Broker(ABC):
    def submit_order(self, order): ...
    def get_order_status(self, order_id): ...
    def cancel_order(self, order_id): ...

# 实盘下单流程（伪代码）
if risk.pre_trade_check(order):        # 事前风控在订单送出前拦截
    oid = broker.submit_order(order)   # 不假设成交，等待交易所回报
    while True:
        st = broker.get_order_status(oid)
        if st in (FILLED, CANCELLED, REJECTED): break
        if timeout: broker.cancel_order(oid); break
        sleep(0.1)
    return st                            # 成交结果必须回写给策略层

1.4 状态机：订单生命周期

订单从创建到终态，经历一组确定的合法状态迁移。状态机是 OMS 的骨架——状态机写对了，断线恢复、超时撤单、部分成交才有依据。

状态机图（行为图 · 细化）：订单生命周期——PENDING→(PARTIAL)→FILLED/CANCELLED/REJECTED

# OMS 订单状态机（简化实现）
ORDER_STATES = ["PENDING", "PARTIAL", "FILLED", "CANCELLED", "REJECTED"]
TRANSITIONS = {
    "PENDING":  {"PARTIAL", "FILLED", "CANCELLED", "REJECTED"},
    "PARTIAL":  {"FILLED", "CANCELLED"},
}

def transition(order, new_state):
    if new_state in TRANSITIONS[order.status]:
        order.status = new_state
        audit_log(order)
    else:
        raise IllegalState(f"{order.status} -> {new_state}")

2. 结构视图（系统由什么组成）

2.1 部署图：四套环境拓扑

从宏观架构看系统部署：四套环境各自独立部署，共享一套数据服务、配置中心与监控设施。

部署图（结构图 · 宏观）：研究→回测→模拟→实盘四套环境 + 共享基础设施，实盘→研究是反馈闭环

2.2 组件图：分层架构（六层核心抽象）

四套环境之所以能复用同一份策略代码，靠的是把整个交易系统垂直切成一组接口：策略只依赖接口，不依赖实现。这套六层抽象是文档最重要的架构决策。

组件图（结构图 · 中间层）：六层抽象接口——数据接入、特征、信号、组合、订单、风险；环境差异收敛到适配器

2.3 类图：核心抽象

向下细化到内部细节：核心类及其依赖关系。这是"六层抽象"的代码形态。

类图（结构图 · 内部细节）：StrategyCore 只依赖六个接口；Broker 有三个环境实现（回测/模拟/实盘）

# 三套 Broker 实现：策略代码完全无感
class BacktestBroker(Broker):
    def submit_order(self, order):
        return fill_model(order, slippage_model=TWAP_SLIPPAGE)

class PaperBroker(Broker):
    def submit_order(self, order):
        return virtual_exchange.match(order)   # 按实时价模拟成交

class LiveBroker(Broker):
    def submit_order(self, order):
        return api.submit(order)               # QMT / xtquant / ccxt / FIX

3. 六大核心模块详解

3.1 数据层

数据是量化系统的"原料"。数据层负责获取、清洗、对齐、存储，同时保证两点铁律：数据必须可信（无未来函数、无脏数据）、必须可复现（回测与实盘拿到的数据格式一致）。

3.2 策略层

策略层承载信号生成与组合构建。它是"策略注册中心"——每个策略实现统一接口、声明参数，系统自动发现、自动映射到仪表盘。策略逻辑本身是各异的，但接口必须统一。

# 策略统一接口（注册中心模式）
class Strategy(ABC):
    params: dict

    @abstractmethod
    def on_bar(self, bar): ...
    @abstractmethod
    def on_signal(self, signal) -> SignalDecision: ...

    def target_weights(self) -> dict:     # 组合层要的目标权重
        return {...}

# 示例：双均线交叉
class DualMA(Strategy):
    def on_bar(self, bar):
        fast = sma(bar, self.params["fast"])
        slow = sma(bar, self.params["slow"])
        if cross_up(fast, slow): return SignalDecision(BUY, weight=0.5)

3.3 回测引擎

回测引擎只保证"语法对"，真正杀死策略的是"逻辑错、数据脏、推断不严"。回测引擎的核心是事件驱动：MarketEvent → Signal → Order → Fill → 绩效报告，逐事件推进，与实盘同一套路径。

活动图（行为图 · 细化）：回测与上线前验证——Walk-forward 滚动窗口 + 多重检验 + 模拟盘试运行

3.4 风控层

风控是量化系统与普通程序的最大区别。它必须独立于策略代码运行，在订单网关与策略之间，毫秒级完成检查。风控分三个时刻：事前（pre-trade）、事中（in-flight）、事后（post-trade）。

# 事前风控：独立于策略进程的规则表
RULES = [  # (scope, key, limit)
  ("account", "gross_exposure", 1_000_000),
  ("symbol",  "position_pct",   0.30),
  ("account", "max_drawdown",   0.20),
  ("account", "daily_loss",     0.05),
]

def pre_trade_check(order, state) -> bool:
    for scope, key, limit in RULES:
        val = state.get(scope, order, key)
        if val > limit:
            audit(order, f"{scope}.{key} {val}>{limit}")   # 任何规则触发立刻留痕
            return False
    return True

3.5 执行层

执行层把"风控放行的订单"变成"交易所里的成交"。最容易忽略的坑：不假设一定能成交。回测里下买单默认下一秒成交；实盘可能有流动性不足、滑点、网络延迟。

3.6 监控与复盘

实盘不是"挂上就跑"。工程重点四大件：订单状态机、对账、事前风控、灰度发布——这四件事任何一件没做扎实，策略再好也会被生产路径上的事故抹平。

4. 实战操作手册（从零搭建一个量化系统）

以下按"最小可用 + 渐进完善"路径，适合个人/小团队从零搭建。技术栈以 Python 生态为例（研究/低频策略场景），高频场景需 C++/FPGA 另行考量。

4.1 技术栈选型

4.2 搭建步骤

1. 建目录骨架：data/ strategies/ backtest/ risk/ execution/ dashboard/ tests/——对应 §2.2 的六层抽象。
2. 写数据适配器：实现 DataSource.get_history()，先接一个免费源，存本地 SQLite。
3. 写第一个策略：双均线交叉（§3.2 示例），实现 Strategy 接口。
4. 写事件驱动回测引擎：MarketEvent → Signal → Order → Fill → 报告（§3.3），含滑点/手续费模型。
5. 写风控模块：仓位（等权/Kelly/波动率目标）、止损（固定/ATR/移动）、独立风控守护（§3.4）。
6. 跑模拟盘：PaperBroker 按实时价模拟成交，与回测对比 PnL 偏差（§1.2 活动图的"偏差可接受?"卡点）。
7. 灰度实盘：小额资金 → 事前风控开启 → 逐步放量 → 随时可回退（§2.1）。
8. 复盘闭环：每日 PnL 归因 + 滑点校准，把结论写回研究（§3.6）。

4.3 常见踩坑与对策

5. 参数指令速查手册

5.1 核心接口速查

5.2 订单类型速查

5.3 风控规则参数速查

5.4 仓位方法速查

6. 开源实现对照

有没有开源项目"完整实现"了本文档描述的一套量化系统？答案是：有，但"完整"要按市场与场景拆开看。没有任何开源项目 100% 覆盖"对账、绩效归因、灰度发布、Kill Switch 兜底平仓"这类生产级运维——这些通常仍是自建部分。这正说明为什么商业量化公司普遍"框架开源、运营闭源"。

组件图（结构图 · 对照）：主流开源项目 × 本文档系统模块的覆盖关系——第一梯队全流程，第二梯队研究/回测，第三梯队垂直场景

6.1 主流开源项目一览

6.2 与本文档架构的模块映射

把各项目对照本文档 §2.2 的六层抽象 + §3 的生产级运维模块，覆盖情况如下（●=完整实现，◐=部分/需自补，○=缺失/范围外）：

6.3 生态资源索引：awesome-quant 精选

§6.1 解决"整框架选谁"，本节解决"组件/工具选谁"。awesome-quant（wilsonfreitas/awesome-quant，29.4k+ stars）是量化金融开源库的策展目录，按约 19 大主题收录 Python/R/Julia/Java/Rust 等各语言项目，适合当作"找工具的入口"。以下按本文档六层架构精选高频库（与 §6.1 框架级条目不重复）：

数据层：行情源与存储

特征/因子层：数值、统计与时序建模

技术指标

回测引擎（§6.1 之外的补充）

组合优化与风控

期权/衍生品定价（研究向工具）

实盘/执行（§6.1 之外的补充）

附录：监管与合规

量化/程序化交易受所在司法辖区监管，上线前必须单独审计：

文末提示：本文聚焦工程架构，不构成投资建议或交易系统认证；文中接口、状态机、阈值仅用于阐释方法论，模拟盘的盈利从来不能保证实盘可复制。